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ABSTRACT 

Early testing of requirements can decrease the cost of remov- 
ing errors in software projects. However, unless done care- 
fully, that testing process can significantly add to the cost of 
requirements analysis. We show here that requirements ex- 
pressed as topoi diagrams can be built and tested cheaply - 
using our SP2 algorithm, the formal temporal properties of a 
large class of topoi can be proven very quickly, in time nearly 
linear in the number of nodes and edges in the diagram. 
There are two limitations to our approach. Firstly, topoi dia- 
grams cannot express certain complex concepts such as itera- 
tion and sub-routine calls. Hence, our approach is more use- 
ful for requirements engineering than for traditional model 
checking domains. Secondly, our approach is better for ex- 
ploring the temporal occurrence of properties than the tem- 
poral ordering of properties. Within these restrictions, we 
can express a useful range of concepts currently seen in re- 
quirements engineering, and a wide range of interesting tem- 
poral properties. 

Keywords 

Formal methods, requirements engineering, model checking, 
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1 INTRODUCTION 

The case for more formality in requirements engineering is 
overwhelming. Many errors in software can be traced back 
to errors in the requirements [32]. Often, the conception of 
a system is improved as a direct result of the discovery of 
inadequacies in the current conception. The earlier such in- 
adequacies are found, the better, since the cost of remov- 
ing errors at the requirements stage can be orders of mag- 
nitude cheaper than the cost of removing errors in the final 
system [33]. 

The benefit of formally checking a system is that formal 
proofs can find more errors than standard testing. A single 
formal first-order query is equivalent to many white-box or 
black-box test inputs [19]. 

The cost of rigorous requirements engineering may be im- 
practically high. These costs include: 

The modeling cost: Analysts must create a systems model 
and a properties model. Both models are in some 


machine-readable form. The properties model is often 
much smaller than the systems model and contains a 
formal temporal logic J description of the invariants that 
must be proved in the systems model. 

The execution cost: A rigorous analysis of formal prop- 
erties implies a full-scale search through the systems 
model. For example, if a given systems model has n 
variables each of which may take on a finite number of 
unique values m, then the size of the state space asso- 
ciated with that model is m n . This space can be too 
large to explore, even on today’s fast machines. Despite 
extensive research into speeding up this search (see our 
Related Work section), analysts often have to painstak- 
ingly rework the systems and properties models into 
more abstract and succinct forms that are small enough 
to permit formal analysis. 

The personnel cost: Analysts skilled in formal methods 
must be recruited or trained. Such analysts are gener- 
ally hard to find and retain. 

The development brake: The above costs can be so high 
that the requirements must be frozen for some time 
while we perform the formal analysis. Hence, one of 
the costs of formal analysis is that it can slow the re- 
quirements process. Slowing down the requirements 
process is unacceptable for fast moving software com- 
panies, such as the start-up dot. corns. 

Ideally, a method for reducing the cost of testing require- 
ments would eliminate the execution cost and reduce the 
cost and skill involved in building the properties and systems 
models. If achievable, such a method would also reduce the 
personnel cost, since it would not require such highly-skilled 
analysts. Having reduced the personnel, modeling, and exe- 
cution costs, this hypothetical method would inevitably de- 
crease the development brake. 

Some progress has already been made in reducing the cost 
of properties modeling using temporal logic patterns . Dwyer 
et.al. [9, 10] have identified patterns within the temporal logic 

‘Temporal logic is classical logic augmented with some temporal oper- 
ators such as \2X (always X is true), OX (eventually X is true), OX (X 
is true at the next time point), X (J Y\ (X is true until Y is true). 
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Importance [deformat ion] 


Figure 1: An example topoi from [7]. The formal semantics for topoi is described below. Informally, we say that -I- approxi- 
mates “encourages” while — approximates “discourages”. 


formulae seen in many real-world properties models. For 
each pattern, they have defined an expansion from the intu- 
itive pseudo-English form of the pattern to a formal tempo- 
ral logic formulae. In this way, analysts are shielded from 
the complexity of formal logics. For example, the simple 
pseudo-English statement 

always(brake — on) between (danger = seen) and(car = stop) 

can be automatically expanded into the more arcane formal 
statement: 

□((danger = seen A !(car = stop) A 0 (car = stop)) 

— ► ( brake = on U ( car = stop))) 

One drawback with temporal logic patterns is that while 
complex temporal formula can be automatically generated 
from intuitive pseudo-English, the execution cost remains. 
That is, even though we can quickly build the properties 
model, we may not be able to execute all of that properties 
model. 

In this article, we argue that we can greatly reduce the exe- 
cution cost for a class of systems models seen in the require- 
ments stage, and for a large class of temporal logic prop- 
erties. In our approach, we use temporal logic patterns to 
reduce the cost of properties modeling, and optimization to 
reduce the execution cost. The key to this reduction is SP2, 
a new algorithm for testing temporal properties of topoi , 
which are statements of gradual influences between vari- 
ables. Topoi can represented graphically by topoi diagrams , 
an example of which is shown in Figure 1. Topoi are quick 
to sketch, and so (for requirements that are topoi-compatible) 
our approach also reduces the systems modeling cost. 

These cost-reduction benefits can only be realized if we ac- 
cept certain restrictions: 


• Our approach limits the kinds of properties that can be 
tested. 

• The systems model must be expressed as topoi dia- 
grams. Topoi are not very expressive and excludes 
statement such as first-order assertions, iteration, sub- 
routine calls, and assignment. 

• Due to these language limitations, our approach is not 
suitable to domains that need the excluded statements; 
e.g. complex protocols seen in concurrent processes. 

These restrictions are not fatal to the modeling process, at 
least at the requirements stage: 

• We will describe how to quickly recognize inadmissible 
properties statements. Further, we will use the Dwyer 
et.al. survey to show that within the limits to the prop- 
erties language, we can represent a wide range of useful 
temporal logic properties. 

• We will show that topoi diagrams are sufficient to rep- 
resent diagrams seen in certain approaches to require- 
ments engineering and recording design rationales. 
Hence, when we say that this approach is practical and 
useful, we really mean practical and useful for early life 
cycle requirements discussions only. 

This worked is based on Feldman & Compton’s study of 
the validation of topoi [11, 12] (which they called qualita- 
tive compartmental models). Menzies tried to optimize that 
validation process and offered an implementation that was 
orders of magnitude faster than the validation engine built by 
Feldman & Compton. However, he could not reduce the ex- 
ponential upper-bound on the runtimes [21-23]. Assuming 
a certain restriction on topoi edge types, Cohen, Menzies, 
Waugh and Goss showed that the cost of checking tempo- 
ral properties of topoi-based simulation is a function of the 
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number of time-ticks in the query [24, 25]. This paper im- 
proves significantly on the Menzies et.al. result. We assume 
the same restriction as Menzies et.al. and introduce SP2, a 
nearly linear-time algorithm for checking a large class of in- 
teresting temporal properties (for space reasons, we describe 
the full details of that algorithm elsewhere [27]). Also, we 
describe an implementation of SP2 which, in at least one do- 
main, out-performs a state-of-the-art temporal logic model 
checker (SPIN [15]). 

2 About Topoi 

Our approach assumes that requirements systems models are 
expressed in the form of topoi; i.e. statements of gradual 
statements such as (i) the more X, the more Y; (ii) the less X 
the less Y; (iii) the more X, the less Y; or (iv) the less X the 
less Y. Dieng et.al. name such statements “topoi’* and give 
numerous examples from their records of interviews with ex- 
perts [7]. For example: 

The more there is water infiltration in the roadway 
body, the worse the foundation risks to be. 

The higher the speed of the vehicles, the more im- 
portant the measure of importance relative to the 
roadway comfort. 

When the geometry increases, the mass increases 
and the frequency decreases. 

If there is a punctual undressing and if the road- 
way is between five and fifteen years old , then the 
causes ” too old coating " is all the more certain 
since the roadway is older. 

Our experience has always been that the systems modeling 
cost with topoi is very low. Topoi graphs can be quickly 
generated in the requirements stage. Two feuding stakehold- 
ers with two marker pens and one whiteboard can generate 
many, many topoi in just a few hours. 

Topoi graphs can be found in many domains. Figure 1 
showed a topoi from an insurance domain using the graph- 
ical notation of Dieng’s 3DKAT tool. Figure 2 show some 
Mylopoulos-style soft-goal graphs [28,29]. Soft-goal graphs 
represent gradual knowledge about non-functional require- 
ments. In Figure 2, an expert describes how to increase 
business flexibility. Figure 3 shows a “questions-options- 
criteria” (QOC) graph from the design rationale commu- 
nity [34]. In such QOC graphs, questions suggest options 
and deciding on a certain option can raise other questions. 
Options shown in a box denote selected options. Options 
are assessed by criteria and criteria are gradual knowledge; 
i.e. they tend to support or tend to reject options. QOCs can 
succinctly summarize lengthy debates; e.g. 480 sentences 
uttered in a debate between two analysts on interface options 
can be displayed in a QOC graph on a single page [20]. 
Figure 5 shows topoi generated from the requirements of a 
rule-based legal system, shown in Figure 4. This translation 


usability performance 


flexibility 


flexible 
work maintainability 

patterns 

I + 


and 



sharing of task 

information switching 




Figure 2: A soft-goal graph: the and node denotes that both 
sharing of information and task switching are enabled by 
flexible work patterns. 


Criterion3 



Criterion 1 


Option la 




Figure 3: A questions-options-criteria graph from [34] 


assumes that propositions in the rule base are modeled as 
a belief/strength pair where the strength is some continuous 
number. 

When collected from multiple stakeholders, gradual state- 
ments can be quite complex, quite large, and contain feed- 
back loops. Smythe extracted a list of gradual influences 
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if infant or moron 
if guilty 
if «g« < 1 

if legal ly_r«9pon>ibla and guilty 
if motive and means and opportunity and 
if guilty and not legal lyresponeibla 


then not legallyresponsibls. 
then jail, 
then infant, 
than jail. 

witnesses then guilty. 

then not jail. 


Figure 4: Rule-based requirements from a legal system. 

+ 

i- 

legally 


age<7 - 


infant 



responsible 

i 

and2 


guilty ^ J a ‘l 


Figure 5: Topoi from Figure 4. 



Figure 6: The Smythe ’87 theory. From [35]. The diagram 
shows statements of gradual knowledge relating to labora- 
tory experiments on mammals. 



Figure 7: A large topoi with many loops. 


from a set of articles from different authors relating to human 
internal physiology. The resulting network contains loops; 
see Figure 6. The experiments described later in the paper 
are based on the large topoi of Figure 7. 

A pre-experimental concern is that informal topoi are so 
under-defined that we could use them to infer any proper- 
ties at all. This turns out not to always be the case. Recall 
Figure 2 and the fragment: 

usability ^ flexibility performance 
Note that there is no way to explain the 


output of { flexibility f} from the input of 

{usability performance t}. That is, while topoi are 
over-generalized, they may still be restrictive enough to 
demonstrate what cannot be proved. We describe below 
experiments which show that large real-world topoi can 
be restrictive enough to block an interesting number of 
temporal properties. 

Topoi: Formal Semantics 

Formally, we say that a topoi is a directed, possibly cyclic 
graph G containing vertices and edges < V, E >. E are the 
connectors between variables and are one of a set of pre- 
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defined types; e.g. or — That is: 

Ei = Vi 4 Vj or Vi V, 
G = <V r ,£> 


The vertices of a topoi can be assigned a finite number of 
values; e.g. up, down or steady. These values model the 
sign of the first derivative of these variables (i.e. the rate 
of change in each value). X ^ Y denotes that Y being up or 
down could be explained by X being up or down respectively. 
That is: 


Vi^V, 


Vi t implies Vj t 
Vi 4 implies Vj 4 


(where t and 4 denote up and down respectively.) 


X -y Y denotes that Y being up or down could be explained 
by X being down or up respectively. That is: 


Vi -> Vj 


{ Vi t implies Vj 4 

Vi 4 implies Vj t 


( 2 ) 


Tacit in our topoi diagrams are conjunctions of influences. 
We can view topoi as influences splashing around pipes that 
connect tubs. Pairs of competing influences can cancel out. 
That is, we can explain the level of water in a tub remaining 
steady via conjunction of competing upstream influences; 
eg. 

(Vi t implies Vj f) \ / (V t AV* |) \ 

and I implies I implies I 

(Vfc i implies Vj \) ) \ (Vj = steady) ) 

(3) 

This formal semantics is sufficient to guide the translation 
of topoi for a formal model checker such as SPIN. Figure 8 
shows the results of such a translation of Figure 6. In this 
figure, all the nodes have the values up, down , steady and 
unknown (which is a placeholder for the initial conditions). 
Also, for convenience, all systems model inputs X are de- 
clared to be X c h g variables with values arrived , left denot- 
ing the differences between these variables in different ex- 
periments. For example, if we increase the injections of dex, 
then we also say that dex c ^ g = arrived. 

Proving Formal Properties in Topoi 

We can test topoi using libraries of expected or desired be- 
havior. Such libraries can be quickly built via interviews 
with users. We have found it useful to structure these in- 
terviews in an 00 framework. After generating use cases 
and particular scenarios [18], we ask our users to clarity ex- 
actly what are the expected inputs and required outputs for 
each scenario. This generates two artifacts. Firstly, it leads 
to topoi graph describing how they think influences should 
propagate around a systems model. Secondly, it leads to the 
formulation of properties models of the form: 

When I do this, / expect to see that. 


•define DOWN 0 
•define STEADY 1 
•define UP 2 
•define UNDEF 3 
•define ARRIVED 0 
•define LEFT 1 

byte chgcoldswim » UNDEF /• chg_cold_swim - (ARRIVED, LEFT} */ 


byte ehg_dex - UNDEF /* chg_dex = (ARRIVED , SWIM} */ 
byte cold_»wim - UNDEF /* coldsvim « (DOWN, STEADY, UP} */ 
byte dex - UNDEF /• dex = (DOWN, STEADY, UP} */ 
byte temp ■ UNDEF /* temp * { DOWN , STEADY , UP } */ 
byte nna - UNDEF /* ruia - { DOWN , STEADY , UP } •/ 
byte acth « UNDEF /* acth * (DOWN. STEADY, UP} */ 
byte cortico * UNDEF /* cortico * { DOWN , STEADY , OP } •/ 


active proctype amytheT { 
if 

: : dex -- UNDEF > dex - DOWN 
: ; dex -- UNDEF ■> dex = STEADY 
: : dex -- UNDEF > dex » UP 

fi; 

if 

: ;cold_ewim -= UNDEF -» cold_swim * DOWN 
; ; cold_svrim UNDEF -> coldswim - STEADY 

:cold_swim UNDEF -» cold_awim * UP 

fi. 
if 

■ ;chg_dex -« UNDEF -> chg^dex * ARRIVED 
: chg_d«x ** UNDEF -> chg_dex * LEFT 

f i; 
if 

: :chg_cold_awim » ■ UNDEF -> chg_cold_»wim * ARRIVED 
; chg_cold_awifn UNDEF -> chg_cold_awim « LEFT 

f i; 
if 

: : chg_dex ARRIVED -> temp » UP 
: : chg'dex LE=T -> temp « DOWN 
fi; 
if 

: ; chg_cold_swim ■■ ARRIVED -> nna ■ UP 
: : chg_cold_awim ■ * LEFT -> nna » DOWN 

fi; 

do 

: (chg cold swim = ■ ARRIVED fcfc temp r » UP) -> nna • STEADY 
: : (chg_cold_»wim -- LEFT temp DOWN) -> nna = STEADY 
::temp * * DOWN -> nna » UP 
: ;temp UP -> nna * DOWN 
:temp =* DOWN -> acth * UP 
::temp UP -> acth ■ DOWN 
: :nna UP acth * UP 
::nna DOWN -» acth * DOWN 
: : acth UP -> cortico - UP 

: : acth DOWN -> cortico » DOWN 

::cortico =» UP -> temp - Up 
: (cortico « « UP frt chg_dex *3 LEFT) -> temp * STEADY 
::cartico * - DOWN -> temp * DOWN 

:: (cortico == DOWN chg_dex ARRIVED) -> temp > STEADY 
: (temp == UP tit nna =.* UP) -» acth * STEADY 
: : (temp =* DOWN 6.i nna = =■ DOWN) -> acth = STEADY 
od ; 

} 


Figure 8: Figure 6 expressed in the PROMELA language 
used in SPIN model checker [15]. 


or, in the language of temporal logic used in (e.g.) SPIN: 

□ ( Inputs — > 0 Outputs) (4) 

i.e. always the inputs lead, eventually, to the outputs. 

We encounter problems if we use Equation 4 to check large 
topoi using standard model checkers. While SPIN checks 
Equation 4 against Figure 8 in less than a second, it can fail to 
terminate for larger systems models. In one study, we offered 
40 properties of the form of Equation 4 to SPIN along with 
Figure 7 expressed in the same format as Figure 8. Given 
100MB of maximum RAM, SPIN ran out of memory for 
most of the properties. We suspected that the search space 
was too big. Figure 7 contains 80 variables, each of which 
has at least the values up, down, steady, undef', i.e. total 
space of options at least of size (4 80 ~ 10 48 ). In a sec- 
ond study, we reduced the size of the system by removing 
the steady values. This shrank the options to (3 80 « 10 38 ). 
However, even in this reduced system, SPIN ran out of mem- 
ory and failed to prove anything for 29 of the 40 proper- 
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ties [31]. 

In summary, while theoretically we can assess topoi using 
standard model checkers, in practice, this may not be feasi- 
ble. 

3 SP2: A Model Checker for Topoi 

While general topoi defeat general-purpose model checkers, 
specialized model checkers can quickly check the temporal 
properties of a restricted class of topoi. Consider a topoi 
containing two-valued nodes connected by the “4*” and ” 
edges defined in Equation 1 and Equation 2. Such a topoi has 
symmetric edges ; i.e. each edge comments on a connection 
of every upstream node's value to every downstream node's 
value. Menzies et.al. showed that when every edge of a sym- 
metric topoi comments on all the values of its downstream 
vertices, then the state space rapidly saturates [24, 25]. That 
is, the granularity of the time axis reduces to the number of 
variables in that theory. For example, in a systems model 
where every variable has only two values, everything that is 
reachable can be reached in two time ticks. 

Using the result of Cohen et.al we have defined SP2, a spe- 
cialized model checker for symmetric topoi [27,31]. SP2 is 
a variant of Dijkstra’s shortest path algorithm [6, 8]. The al- 
gorithm inputs a symmetric topoi with edge set E, node set 
V , and an initial set S C V. S contains some value assign- 
ments to some nodes and represents the initial conditions of 
the system. The algorithm outputs a set of edges Z with the 
following properties: 

• Z is a collection of trees spanning all the nodes reach- 
able from the inputs. 

• For any reachable node z 9 Z contains the shortest topoi 
path from the inputs to z. 

• The nodes of V spanned by Z are partitioned into two 
sets S' and T\ where: 

- No edge of Z passes from T* to S'. 

- Each set is consistent; that is, will not contain both 
x t and x 

Elsewhere, we have proved that SP2 generates S' and T l cor- 
rectly, and runs in 0( \V\ + |E?|log|V r |) time in the worst 
case [27]. SP2 is efficient due to its exploitation of satura- 
tion. While spreading out over the topoi, it maintains two 
sets of nodes: the now set (S') and the later set ( T f ). If 
the algorithm reaches a node that contradicts something else 
in the now, it moves the new node into the later set. The re- 
peated application of this rule on a 2-spaced symmetric topoi 
results in a fast division of the nodes reachable from the ini- 
tial conditions into the two sets S' and T* . 

Using SP2, we can very quickly explore temporal properties 
that can be proved in two time ticks. A large range of in- 
teresting queries can be executed in two time ticks (but see 
below for a discussion on the properties that require more 
than two time ticks). Once S' and T ( are generated, we can 
convert our temporal properties into set membership tests of 


exp 

— ► □ exp 

//always 


| 0 exp 

//eventualy 


1 Oexp 

//next 


| exp W exp 

// weak until 


j exp (J exp 

//until 


| exp A exp 

//conjunction 
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| exp -* exp 
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| ! exp 

//negation 


1 x 
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exp W exp 

-► (exp (J exp) A □ exp 

□ exp 

-+■ (x £ now’) A(x£ later’) 

0 exp 

— ► (x £ now’) V ( x E later’) 
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expi U exp 2 
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expi -► exp 2 

-> (y £ now’) V ((x £ now’) A (y £ now’)) 

expi fPexp 2 

(expi (J exp 2 ) V (□ expi ) 

1 exp 

— ► (x £ time) 


X 

— ► (x £ time) 


time 

—*■ now’ | later’ 


now’ 

— ► s’ 


later’ 

-+ 1* 



Figure 9: Rewrite rules for converting linear temporal logic 
expressions into set membership tests of SP2’s S' ,T' . 

these sets. Figure 9 and Figure 10 show conversion rules for 
common temporal properties. 

SP2 offers two major other advantages over standard tempo- 
ral reasoning: 

1 . SP2 runs, terminates, returns Z, and then we perform 
set membership of Z to prove our properties. That is, 
we do not test for properties till after SP2 terminates. 
Hence, the inference time is not much affected by the 
complexity of the properties to be tested. 

2. SP2 uses a shortest-paths tree to build its proofs. That 
is, when explaining how properties were reached, SP2 
will generate the shortest explanation possible, Hence, 
a user of SP2 need not wade through mountains of trace 
files in order to understand how the properties were 
proved. 

Experiments with SP2 

Figure 1 1 shows a comparison of SPIN vs SP2 using prop- 
erties of the form of Equation 4 and the systems model of 
Figure 7. Of the 40 properties which were analyzed by both 
SPIN and SP2, SPIN was able to return a verification result 
in only 1 1 out of 40 cases (27.5%) before running out of 
memory. In every case where SPIN did return a verification 
result, SP2’s result was in agreement. 

Regarding computer resources, SP2 used less than 1% of the 
RAM required by SPIN. Also, in the case of the unprovable 
properties, SP2 terminated in less than a second CPU time 
while SPIN took much longer. 
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Figure 10.A: Absence properties: p is false 


Property 

LTL 

SP2 

Globally 

□(!p) 

p£S’Ap£t 

Before R 

0R->(!pl)R) 

ReS'VR£T’Vp£S’ 

After Q 

□(Q-> D(!p)) 

(QeS’V(p£S’Ap£T’))A (Q€T WH 

Between Q and R 

□((Q A'RA 0 R)-K!pUR)) 

(Q£T’Vp£T’)A (Q£S’VReS’VR£T’Vp£S’) 

After Q until R 

□(Q AiR-KlpWTl)) 

(QffT’VReT’) A(Q^S’VR6S'V(p0S , AReT’)) 


Figure I0.B: Existence properties: p becomes true 


Globally 

0 (p) 
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Before R 
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After Q 

□(!QV0(QA0p)) 

peT’V((Q£S’Vpe s ’)AQ£T’) ! 

Between Q and R 

□(Q A'R - K!R^(pA'R)» 

QeS’AQeT’ApeT’A(Res’VpeS’VRsrn 

After Q until R 

□(Q A'R—K-RLKpA'R)) 

QeS’AQeT’A (ReT'Vper)A (ReS’VpeS’VCpeT'AR^T’)) 


Figure 10.C: Universality: p always true 


Globally 

□(p) 
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Before R 
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After Q 

□(ch n(P» 

(Q£S’V(P€S’Ap€T’))A Q^T’VpeT’) | 

Between Q and R 

□((QA’RA 0R)-HpUR» 

Qes’VRes’VR£T’\/p€S’ 

After Q until R 

□(QA!R->(pH'R)) 

Qes’AQeT’A(Res’Vp€S’)A (ReT’VpeT 1 ) 


Figure 10.D: Precedence: S precedes p 
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\pWS 
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Figure 10. E: Response: S responds top 
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□((QA’RA OR)-* 
(p->(!RU(SA!R)))UR) 

Inexpressible: needs > 2 time ticks 

After Q until R 

□(QA’R-* 

((p->(!RU(SA’R)))^)) 

QeS'AQeT’A (ReT'Vser\/p^T’) 


Figure 10: Common temporal logic queries converted into set membership tests of SP2*s S' ,T* . This table was generated by 
applying the re-write rules of Figure 9 to a survey of common temporal logic queries [9, 10]. From [31]. 
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?? 
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21 
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11 
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unproved 
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proved 
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0 

unproved 

proved 

0 

| RAM used (max) 

100MB 

< 1MB 



Figure 11: Proving properties of Figure 7 in SPIN and SP2. 
“??” denotes that SPIN did not terminate in 100MB of RAM. 


We mentioned earlier that one pre-experimental concern 
with informal topoi is that they are so under-defined that we 
could use them to infer any set of properties at all Figure 1 1 
shows that this is not always true. In the case of 8 of the 40 
properties, SP2 could not prove them across the large under- 
defined topoi of Figure 7. 

Limits to SP2 

What are the practical implications of SP2’s restrictions? We 
discuss below two important implications: restrictions of the 


properties that can be proved and the need for special tools 
to handle conjunctions. 

Inadmissible Properties 

Figure 12 shows Dwyer et.al.’s classification of over five 
hundred linear temporal logic (LTL) properties [9, 10]. Those 
properties divide into eight groups and each group contains 
the five temporal scopes seen in Figure 10; i.e. globally; be- 
fore event R\ after event Q ; events Q and it!; and after event 
Q until event R. || of these scopes are expressible in terms 
of two time ticks [31]. The inexpressible scopes all require 
proving some ordering of > 2 events. By definition, such 
an ordering cannot be expressed using merely the two time 
intervals of S' and T' generated by SP2. 

Figure 12 shows us that SP2-style inference on symmet- 
ric topoi can say more about the occurrence of a given 
event/state during system execution than about the ordering 
in which multiple events/states occur. It is a simple matter to 
detect the temporal properties that are inadmissible for SP2. 
All such properties require more than two time ticks; e g. 




Occurrence ( 5+5 ^^° 15 ) 


( Absence (§) 
Universality (|) 
Existence (|) 

Bounded Existence (|) 


Order ( ^ ) 


Precedence (|) 
Response (|) 

* Chain Response (§) 
Chain Precedence (§) 


Figure 12: Coverage of the Dwyer corpus of temporal prop- 
erties by SP2. Each right-hand-side group of properties con- 
tains five scopes. Fractions denote how many of those scopes 
can be handled by SP2, as seen in Figure 10. Adapted from 

[31] 


until operators nested to a depth greater than two such as:. 
{day — Sunday (^J {day = monday day — tuesday J j 


Handling Conjunctions 

Another problem is that symmetric topoi have no special 
knowledge of and-nodes. This can lead to some less-than- 
desirable results. Consider the following topoi: 

usability -4 flexibility f- performance 

Equation 3 says that the conjunction of competing upstream 
influence can result in a steady value in a downstream vari- 
able; i.e. 

usability t -4 andOOl 
performance J. — > andOOl 

andOOl -4 flexibility = steady (5) 

where andOOl is an and-node especially created for this 
conjunction. A reasonable temporal interpretation of and- 
nodes is that all pre-conditions must appear before or at 
the same time as the post-conditions. Suppose we seek to 
flexibility - steady € S', but SP2 computes a node partition 
in which usability t € V and performance^ € V . We would 
like to be able to coax these pre-conditions back in time to 
S' such that they do not occur at a time that is later than 
flexibility = steady G S'. 

Another case where we want to coax edge weights is the bad- 
and situation. The rules of symmetric topoi require that if 
we create the edges shown in Equation 5, then we must also 
create the following complementary rules: 

usability l — > andOOl 

performance t -4 andOOl 

andOOl -4 flexibility — steady (6) 

where X is an invented node representing “ all the o ther 

values of X ” The addition of the nodes andOOl and 


flexibility = steady is required to ensure the symmetry prop- 
erties upon which SP2 is dependent. However, they are just 
nonsense symbols that should never appear in any explana- 
tion of how certain inputs lead to certain properties. That 
is, pathways from inputs to properties should never include 
these nonsense symbols. Hence, if possible, SP2 should be 
‘coaxed’ into producing shortest path trees in which these 
spurious nodes appear at the leaves. 

SP2 contains a mechanism to implement such coaxing: each 
edge in the topoi is augmented with an edge weight, which 
SP2 uses to compute shortest paths - the length of a path is 
simply the sum of the weights of the edges along the path. 
At the core of SP2 is a priority queue. At runtime, the next 
edge to be explored is one of the edges with lowest weight 
within the queue. This means that by adjusting weights and 
re-running the algorithm, we can choose to explore edges at 
some earlier time or later time. Hence, to coax usability t and 
performance 4, into S', we can adjust the weights upstream 
of those nodes. In coaxing, the weights can be adjusted ar- 
bitrarily, provided that the any symmetric pair of edges re- 
ceives the same weight for both edges. Elsewhere [27] we 
define a set of minimal edge adjustment heuristics which in- 
put SP2’s shortest path tree Z, the cut set C containing the 
edges that connect S' to T and which outputs changes to the 
edge weights. 

A major pre-experimental concern was that the nearly linear- 
time processing of SP2 could be followed by an indefinitely 
long coaxing process. After much experimentation, we can 
report that we have never seen this worst-case behavior in 
practice. In those experiments we used SP2 to explore ran- 
domly generated properties of the form of Equation 4 over 
dozens of randomly generated topoi graphs. We varied topoi 
fanout (2 to 6 edges per node) and the frequency of and- 
nodes (from 5% to 75%). Each experiment was terminated 
when the % of provable properties reached some plateau. In 
all the experiments, the plateau was reached after < 5 iter- 
ations of SP2+coaxing. Also, the plateau reached after 10 
coaxes barely changed in up to 100 coaxes. Further, SP2 
never used more than 1MB of memory or one minute of run- 
time. Our conclusion from these experiments is that the need 
for heuristic coaxing does not diminish the time and space 
efficiency of SP2. 

4 Related Work 

We are hardly the first to explore formal methods for require- 
ments engineering. For example: 

• In the KAOS system [36], analysts generate a properties 
model by incrementally augmenting object-oriented 
scenario diagrams with temporal logic statements. Po- 
tentially, this research reduces the costs of formal re- 
quirements analysis by integrating the generation of the 
properties model into the rest of the system develop- 
ment. Our reading of the KAOS work is that while the 
resulting model may be more formal, the level of skill 
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required to write the temporal logic can significantly in- 
crease the personnel cost. Further, the extra time re- 
quired for the augmentation could increase the effect of 
the development brake. 

• Schneider et.al. [33] explored reducing the manual 
modeling costs using lightweight formal methods. In 
the lightweight approach, only partial descriptions of 
the systems and properties models were constructed us- 
ing the SPIN formal analysis tool [15]. Despite their 
incomplete nature, Schneider et.al. found that such par- 
tial models could still detect significant systems errors. 
While exciting research, this approach still incurs the 
personnel cost since scarce expertise is required to drive 
tools like SPIN. 

Nor are we the first to explore optimizing temporal logic 

model checking. Elaborate tools have been developed to 

tame the state space explosion problem including: 

Abstraction or partial ordering: Only use the part of the 
space required for a particular proof. Implementations 
exploiting this technique can restrain how the space is 
traversed [14, 26], or constructed in the first place [13, 
33]. 

Clustering: Divide the systems model into sub-systems 
which can be reasoned about separately [2, 4, 30, 37]. 

Meta-knowledge: Avoid studying the entire space. Instead, 
only study succinct meta-knowledge of the space. One 
example used an eigenvector analysis of the long-term 
properties of the systems model under study [17]. 

Exploiting symmetry: Prove properties in some part of the 
systems model, then reuse those proofs if ever those 
parts are found elsewhere in the systems model [3]. 

Semantic minimization: Replace the space with some 
smaller, equivalent space [16] or ordered binary deci- 
sion diagrams [1]. For example, the BANDERA sys- 
tem [5] reduces both the systems modeling cost and 
the execution cost via automatically extracting (slicing) 
the minimum portions of a JAVA program’s bytecodes 
which are relevant to particular properties models. 

While the above tools have all proved useful in their test do- 
mains, they may not be universally applicable. 

• Certain optimizations require expensive pre-processing, 
such as [17]. 

• These methods may rely on certain topological features 
of the system being studied. Exploiting symmetry is 
only useful if the system under study is highly sym- 
metric. Clustering generally fails for tightly connected 
models. 


Also, for requirements engineering, systems like BAN- 
DERA are not suitable. BANDERA only works on imple- 
mented systems; that is, not until long after the requirements 
phase has ended. 

Hence, in the general case, only small models can be tested. 
Further, these models must be precisely specified. In con- 
trast, this work describes methods for quickly proving prop- 
erties in large models that have been hastily sketched. 

5 Conclusion 

We need better formal testing for our requirements. Apply- 
ing formal methods can lead to an unacceptable brake on the 
development process. Cost-effective formal methods have to 
reduce the cost and skill involved in modeling systems and 
their properties. The cost of properties modeling can be re- 
duced via temporal logic patterns. However, the execution 
cost of the resulting properties model may require expensive 
rework of the properties generated from the patterns. 

In the specific case of requirements that can be mapped into 
symmetric topoi, we have shown that the systems modeling 
cost is reduced (since the topoi can be sketched quickly). For 
such symmetric topoi, we can reduce the execution cost for 
proving formal properties to time that is nearly linear on the 
number of edges and nodes in the topoi. 

The combination of easy specification of properties and sys- 
tems models implies that the personnel cost of formal mod- 
eling is reduced. This cost-reduction can only be achieved in 
domains were the systems model can be expressed as topoi 
and the properties model refers more to temporal occurrence 
properties than temporal ordering properties. We have ar- 
gued that requirements engineering is one such domain. 

Having built the SP2 engine, our next goal is the construc- 
tion of a shell that exploits this engine. Our current research 
goal is the construction of the RAPTURE shell. RAPTURE 
exploits SP2 to enable the fast formal analysis of topoi- 
compliant descriptions of software systems. 
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